Structural Refactor #87
Conversation
|
After testing it through a private functional test, I would say the effort to make this refactor really pays off. It's been a game-changer for my development process. Before that, I had to include every suite possible, which was a real headache and made the codebase unnecessarily bloated. Now, I can just choose whatever crypto suite I want, say for my ESP32 code now. It's given me so much more flexibility and control over my projects. While I didn't get a chance to run a real test on the ESP32 hardware itself (which is definitely on my to-do list), I used the following setting in my Windows binary test to simulate the environment: This is a bare-minimum dual TLS1.3/TLS1.2 compliant setting, using only TLS13_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (for TLS1.2). But if I ran only TLS1.3, it would shave off about 300KB from the binary, down from 1MB to 713KB (30% binary size saved!). That's a scary amount. It's wild to think about how much space these security protocols take up. This approach allowed me to get a good feel for how the refactored code would perform in a more constrained environment like the ESP32. The results were promising, showing improved efficiency and reduced overhead. It's really exciting to see how this change could potentially optimize performance on embedded systems. I mean, 300KB might not seem like a lot in today's world of gigabyte-sized apps, but when you're working with embedded systems or trying to optimize for performance, every kilobyte counts. And let's be real, the fact that dropping down to only using TLS1.3 and just one suite saves that much space is kind of mind-blowing. It really makes you wonder about the trade-offs between security and efficiency, especially in resource-constrained environments. I guess that's the price we pay for keeping our data safe in transit, right? PS: The environment is simulated using Rustls unbuffered API, which is for running in an embedded, no_std but alloc available environment. Together with this provider being no_std friendly, this is probably the first publicly-maintained provider that could run on MCUs officially. |
|
@stevefan1999-personal it looks like there are conflicts with |
|
@tarcieri the problem is that I re-sorted the entries, so it is not in symphony deliberately...maybe this could be another PR |
|
@tarcieri Maybe merge it soon? btw a new challenger approaches: https://github.com/wolfSSL/rustls-wolfcrypt-provider (also give me the invite for the maintainer status again i didnt receive the invite as i was told in zulip) |
…ing and performance
- Created a new Rust package for testing rustls with real socket connections. - Added Cargo.toml with dependencies for rustls, rustls-rustcrypto, anyhow, log, and env_logger. - Implemented main.rs to set up a TLS server and client using rustls. - Included dummy certificate verification for testing purposes. - Added binary files for certificate and private key in DER format.
…ecify ESP-IDF version
…implementation and restore sec1 support for EcdsaSigningKey
- Updated README.md to include detailed supported cipher suites, feature usage examples, and simplified feature sets. - Expanded validation/README.md with comprehensive descriptions of validation crates, their purposes, and usage instructions. - Added esp32-test/README.md detailing the ESP32 TLS test suite, including setup, features, and troubleshooting. - Created rustls-real-socket-test/README.md for validating TLS functionality using real sockets, with extensive usage and configuration details.
…hm definitions using a macro for improved maintainability
…GitHub Actions workflow
…ut and updating matrix configurations for improved clarity and maintainability
…ication and maintenance
- Simplified the definition of TLS 1.2 cipher suites by introducing the `feature_slice!` macro for conditional compilation based on features. - Replaced repetitive cipher suite definitions in `ecdsa.rs` and `rsa.rs` with a new macro `tls12_ecdhe_cipher_suite!` to streamline the code. - Enhanced the `ALL` and `MAPPING` constants in `verify.rs` to utilize the `feature_slice!` macro for better readability and maintainability. - Added support for EdDSA signature schemes in the verification algorithms. - Refactored RSA hash implementations and verifier constants using a new macro `rsa_hash_and_consts!` to reduce code duplication. - Updated TLS 1.3 cipher suite definitions in `aes.rs`, `chacha20.rs`, and `suites.rs` to use the `tls13_cipher_suite!` macro for consistency. - Improved the organization and clarity of the codebase by consolidating feature checks and reducing boilerplate code.
|
@tarcieri Looks like X448 has some interface change, that I cannot get the public key bytes, so I have to pin it first. But otherwise I consider this very much golden |
|
Aah, looks like that was accidentally removed in RustCrypto/elliptic-curves#1378. I can add it back. Edit: opened RustCrypto/elliptic-curves#1435 |
This PR represents a monumental refactoring effort that transforms
rustls-rustcryptofrom its initial alpha implementation into an almost production-ready, highly modular TLS provider, if performance is not of concern. Spanning 70+ commits over an extended development cycle, this overhaul addresses fundamental architectural issues and delivers a pure-Rust TLS solution optimized for diverse deployment scenarios.📈 Evolution Timeline
Phase 1: Foundation (Initial Implementation)
Phase 2: Feature Expansion & Stability
no_stdcompatibility improvementsPhase 3: Major Structural Refactor
Phase 4: Production Readiness
🔧 Key Technical Changes
🏗️ Architectural Improvements
🔐 Cryptographic Enhancements
🛠️ Infrastructure & Quality
🧪 Testing & Validation
no_stdenvironments)🎯 Benefits & Impact
⚡ Performance & Efficiency
🔧 Developer Experience
🏭 Production Readiness
📋 Migration Guide
Breaking Changes:
Migration Steps:
Cargo.toml✅ Validation Results
This refactoring marks the culmination of extensive development effort, delivering a TLS provider that rivals commercial offerings while maintaining the simplicity and security of pure Rust implementation. The modular architecture ensures long-term maintainability while the comprehensive feature set supports everything from embedded IoT devices to high-performance web servers.